The present invention relates generally to local number portability (LNP) in a telecommunications network, and more particularly to controlling looping of messages in an LNP enabled network.
Currently, local phone service is provided by a single company, such as a Regional Bell Operating Company (RBOC). These companies basically enjoy a monopoly over local phone service within their regions. Thus, efforts are being made to introduce competition into the local phone market to eliminate the monopolies and relieve the need to regulate the industry. Under the current system, however, if customers want to change from one service provider to another, they must also change their phone numbers. This is a serious deterrent to switching service providers and, thus, a hindrance to free and open competition.
To alleviate the problem, the FCC has issued an order for LNP which, in addition to providing other features, will allow a customer to switch between local service providers while keeping the same phone number.
In the existing pre-LNP telephone network, the first six digits (NPA-NXX) of a 10 digit phone number identify a particular switch in a particular geographic region. Switches can route calls between switches based on the NPA-NXX of the dialed number. In an LNP environment, however, this relationship between the NPA-NXX and the physical location of a switch is broken, such that there is no fixed relationship between a dialed number and its geographic location. Many existing telephone services such as calling card services, automatic callback, and services relating to voice mail and voice messaging, however, have been implemented based on this geographic relationship. If the change to an LNP environment is to succeed, existing services (i.e., pre-LNP services) must continue to work in the new LNP environment.
Implementation of LNP is creating new network problems. The call flow diagram of FIG. 1 helps illustrate one of these problems. Take, for example, the *69 call back service where two competing local networks A and B exist in a single geographic region. Suppose a caller 10 in Network A dials *69, and the last person that called caller 10 is a subscriber who has switched from the Network A provider to Network B provider. Ideally, both networks are simultaneously updated with the information that the subscriber has ported and call processing proceeds as shown in FIG. 1. A Service Switching Point (SSP) 12 determines that the call is invoking the *69 call back service which requires assistance from an Integrated Service Control Point (ISCP) 16. SSP 12 launches a message to a Signaling Transfer Point (STP) 14, which directs the message to the appropriate ISCP 16. ISCP 16 determines the Signaling Point Code (SPC) (i.e., the address of a network element) of the appropriate ISCP 17 or STP 18 in Network B and routes the message accordingly. ISCP 17 of Network B checks its database (not shown) and routes the requested information to Network B's SSP 19, which completes the call.
If, as assumed above, each network is updated simultaneously, no problems arise. Under the current LNP requirements, however, the network databases may not be updated simultaneously. Suppose in the previous example that Network A updates its database before Network B. The resulting call processing is shown in FIG. 2. A caller 20 again dials *69, and an SSP 22 determines that the call requires assistance from ISCP 26. The SSP 22 launches a message to the STP 24, which directs the message to the appropriate ISCP 26. The ISCP 26 determines the SPC of the appropriate ISCP 27 or STP 28 in Network B and routes the message accordingly. The database (not shown) associated with ISCP 27 in Network B, however, has not been updated to reflect the fact that the subscriber has ported from Network A to Network B. Thus, when ISCP 27 of Network B checks its database, it determines that the subscriber is still with Network A. ISCP 27 then returns the message to STP 24 of Network A. There, the process begins again. The message will loop back and forth between the networks because the databases have not yet been properly updated.
The looping message will stay in the network until Network B updates its database and the message gets correctly routed or the message is dropped. If the message looping problem is serious, because of extremely high volume or multiple looping messages, the ISCP overload mechanism will automatically detect the overload condition and take the necessary steps to drop messages.
During the interim, however, the looping message consumes network capacity. Assuming it takes approximately 200 ms for a message to reach Network B's ISCP from Network A's ISCP, the round-trip will take 400 ms. This results in the loss of about 3 q/s of capacity for each looping message. For simplicity, the above explanation assumes that only two networks are involved. The drain on capacity would be even more significant if intermediate networks are included in the calculation.
Currently, no mechanism exists that would allow the ISCP to detect looping messages. There is, therefore, a need for a system and method to detect and eliminate looping messages before an overload condition is detected by the ISCP.